home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000307_connolly@pixel.convex.com _Wed Nov 11 01:38:10 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA19113; Wed, 11 Nov 92 01:38:10 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA07932; Wed, 11 Nov 92 01:50:53 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA28223; Tue, 10 Nov 92 18:50:03 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA13695; Tue, 10 Nov 92 18:50:01 -0600
  10. Message-Id: <9211110050.AA13695@pixel.convex.com>
  11. To: Edward Vielmetti <emv@msen.com>
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: proposed registration of type 'text/html' for MIME 
  14. In-Reply-To: Your message of "Tue, 10 Nov 92 18:58:17 EST."
  15.              <m0mp5Tc-00009TC@garnet.msen.com> 
  16. Date: Tue, 10 Nov 92 18:50:01 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >Thanks for the message, Dan.  A few points.
  21. >
  22. >I am not comfortable referencing documents (in an IETF message) that
  23. >are available only via the system in which I'm trying to document.
  24. >I.e. for the purpose of conveying to the IETF what all we're up to
  25. >it would be best to have files in the anonymous FTP area and rendered
  26. >in ASCII.  
  27.  
  28. Point taken. But we can certainly come up with an ASCII version of
  29. http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html . There's no
  30. need to use the HTTP document.
  31.  
  32. And the HTML DTD is a plain ASCII document as is. I'm not sure
  33. if it's available via ftp, but certainly that's not an insurmountable
  34. obstacle.
  35.  
  36. >Calling HTML an "SGML application" is not a bad long term plan.  I
  37. >fear there's some risk in ease of implementation from
  38. >    Content-type: text/sgml; dtd="(string that identifies html.dtd)"
  39. >compared to
  40. >    Content-type: text/html
  41. >and as such I'd prefer to not haul in all of the SGML standard in the
  42. >description of the system, not right up front at least.  Better to
  43. >spec something that you can deliver and play with rather than stretch
  44. >things out to their limits.  
  45.  
  46. Uuugh! Do I have to write a "Misconceptions about SGML" essay? I
  47. never said anything about content-type: text/sgml. I did talk
  48. about hauling the SGML standard in, but that only requires the few
  49. changes I pointed out. There's no need to implement a whole SGML parser.
  50.  
  51. But I'd say ISO 8879 + html.dtd is a better spec for the syntax of
  52. HTML than any english description we can come up with in the near term.
  53. And the existing WWW code works just fine on conforming documents. [It
  54. also groks non-conforming documents, but I don't see any crime in that.]
  55.  
  56. After all, I think this is the intent of the designers of HTML:
  57.  
  58.     HTML is not an alternative to SGML, it is a particular
  59.     format within the SGML rules (an SGML "DTD"). [http.txt]
  60.  
  61.  
  62. And, if we start to enforce SGML compliance, we may be able to do things
  63. like using SGML editors, translators, browsers, etc. If we don't enforce
  64. compliance, we might as well not use SGML at all!
  65.  
  66. >Dan, if 
  67. >    http://info.cern.ch/hypertext/WWW/MarkUp/HTML.dtd
  68. >is in fact something that should get a "public text identifier" (some
  69. >kind of ISBN number?) then we should do it.  That would be a very
  70. >useful document to reference in the comments section.